AWS Transfer FamilyのカスタムIDプロバイダー構成でLambdaを直接統合出来るようになりました

いわさです。

AWS Transfer FamilyではIDプロバイダーとして

• サービスマネージド
• AWS Directory Service
• カスタムIDプロバイダー

が選択出来ました。

従来、このカスタムIDプロバイダーを利用するためにはAPI Gatewayが必要だったのですが、今回のアップデートで、API Gatewayを使わずに、Lambdaのみで認可出来るようになりました。

従来まではAPI Gatewayが必要だった

前述のとおり、従来まではカスタムIDプロバイダーでの認証を行う場合はAPI GatewayをIAM認証でTransfer Familyから利用させ、統合されたLambda関数にてIDプロバイダーへの認証処理と認可レスポンスを行う形でした。

コンソール上も以下のようにAPI Gatewayのエンドポイントを指定する選択肢しかありませんでした。

カスタム ID プロバイダーの操作 - AWS Transfer Family より引用

Lambda統合で構成

早速試してみます。

まずは、Transferを信頼するロールを作成し、S3へのアクセスを許可します。
ここではIwasaHogeAllowSpecifyS3forTransferというロールを作成しました。
このロール作成については従来のAPI Gatewayを使った認可の流れと同じです。

Lambda上で認証して認証結果としてロールを返却します。
つまにどういう認可をさせるかはLambdaの処理次第になっています。

なお、公式ドキュメントではCloudFormationテンプレートでのみ紹介されており、さらに作成されるLambda関数はCognitoで認証していて複雑だったので、今回紹介するにあたってもっとシンプルな以下のような最小のコードにしています。
実際にご利用される際はご注意ください。

def lambda_handler(event, context):
    if event["username"] == "hoge" and event["password"] == "fuga":
        return { 'Role': 'arn:aws:iam::123456789012:role/IwasaHogeAllowSpecifyS3forTransfer' }
    else:
        return {}

Lambda関数の処理としては従来と変わらず、ポリシーベースでTransfer Familyへ認可情報として返してあげるだけです。

他にもLambdaから返却出来るパラメータがいくつかありますが、この辺りは従来のAPI Gatewayでの認証時と変わらないので割愛します。

Working with custom identity providers - AWS Transfer Family

最後に、Trasfer Familyへ作成したLambdaの実行許可を与える必要がありますので、リソースベースポリシーをLambda関数へ追加します。
これを忘れるとテスト時に403エラーになります。

さて、テストしてみましょう。

良さそうですね。

SFTPクライアントでも接続してみます。

問題なく統合、認証することが出来ました。

API Gatewayも使える

API Gatewayは今後は不要なのでしょうか？
API Gatewayを引き続き使うことも可能です。

API GatewayはAWSWAFの統合機能があるので、TransferのカスタムIDプロバイダー認証用のAPIを、AWS WAFで保護することでIPアドレスでのブロックなどWAFの機能をシンプルに、Transfer Familyの認証部分に利用することが可能です。

まとめ

本日は、新機能のLambda統合を試してみました。

簡単なステップでLambda統合ができました。
また、従来とLambda関数自体のインターフェースは変わっていないので、移行コストも低そうです。

しかしLambda統合を無条件で使うというわけではなく、追加のセキュリティレイヤーが必要な場合はAPI Gateway + AWS WAF、それ以外であればシンプルなLambda統合を使えるかなど、検討するのが良さそうかなと思います。